Synchronous distributed groupware applications are being increasingly being deployed on high-latency wide-area networks such as the Internet. For such groupware applications, the major drawback of high-latency networks is the potential decrease in responsiveness. Many synchronous groupware systems available today allow end-users to share state by making distributed copies of the shared state, and keeping the copies consistent via some consistency protocol. When a user updates his copy of the shared state, all users see the update after the consistency protocol runs and, after a certain delay, has consistently updated the replicated copies. In some groupware applications, this delay may be tolerable for users other than the one who initiates the update. However, for the initiator of the update, the delay may become intolerable, since graphical user interface (GUI) gestures will no longer provide adequate visual feedback relative to regular single-user applications.
A solution that is widely employed to solve the general problem of responsiveness in groupware is optimistic execution of updates to distributed shared state. See e.g., Schuckmann, C., Kirchner, L., Schummer, J., and Haake, J. M. (1996) “Designing Object-oriented Synchronous groupware with COAST.” In Proceedings of Computer Supported Collaborative Work CSCW, 1996 [“COAST”]; and Karsenty, A. and Beaudouin-Lafon, M (1993) “An Algorithm for
Distributed Groupware Applications.” Proceedings of IEEE Int'l Conference on Distributed Computing Systems ICDCS '93 [“ORESTE”]. See also patent application Ser. No. 08/863,782 entitled “SYSTEM AND METHOD FOR PROVIDING COLLABORATIVE REPLICATED OBJECTS FOR SYNCHRONOUS DISTRIBUTED GROUPWARE APPLICATIONS,” [“DECAF”] by Banavar et al., filed May 27, 1997 now U.S. Pat. No. 6,425,016. The present invention is commonly assigned with this patent application, which is hereby incorporated herein by reference in its entirety.
Optimistic execution is based on assumptions about the current state of the system. Subsequently, if any assumption turns out to be invalid due to concurrent operations, the conflict is resolved using any of a number of techniques: such as rollback [DECAF]; transformation (see e.g., Ellis, C. A. and Gibbs, S. J. (1989) “Concurrency Control in Groupware Systems,” Proceedings of ACM Conference on the Management of Data SIGMOD '89); or masking [ORESTE]. For groupware applications where shared state is directly visible to end-users, optimistic execution does indeed increase responsiveness, since updates may be exposed to users as soon as they are optimistically applied. Thus, a system that supports optimistic execution is very useful for supporting interactive, transient state within groupware applications.
However, a groupware system that supports optimistic execution alone has limitations. For one thing, external persistent actions such as printing or saving to file should not be performed based on optimistic state. Even for interactive transient state, optimism introduces the possibility of irregular GUI behavior when optimistic assumptions turn out to be invalid, which often causes confusion to end-users. This irregular GUI behavior most commonly takes the form of lost updates (since more “recent” updates have been exposed) or jitter in an application's GUI (as updates are retried and reapplied). Thus, it is important for groupware systems to support both optimistic and some form of pessimistic execution to allow the application programmer to pick and choose what is appropriate to each case.
The aforementioned DECAF application framework for groupware supports both optimistic and pessimistic notifications of updates to distributed replicated state. DECAF extends the so called
Model-View-Controller (MVC) architecture for applications. Framework provided model objects, which hold the application state, are replicatable across distributed sites, and the DECAF system automatically keeps replicas consistent with each other. Controllers, or GUI event handlers, can initiate programmer defined atomic actions on multiple model objects. Programmer defined view objects can be attached to model objects at each site to get notifications of both local and remote updates to the replicated model objects. At the time of attachment of model objects, each view object can be specified to be either optimistic or pessimistic, which determines when the system will notify the view objects. A pessimistic view is guaranteed to get all update notifications in order, and is able to take consistent snapshots of attached model objects. An optimistic view trades off complete accuracy for the performance benefit of immediately notifying updates.
In DECAF, the programmer must statically decide, per view object, whether the view object should be notified optimistically or pessimistically—this decision holds good throughout the application's life. In other words, the DECAF programmer must trade off between view responsiveness and complete view accuracy at application design time. An optimistic view's behavior is justifiable only under conditions of a low rate of concurrent updates, and thus low probability for concurrency control conflicts. Such an assumption of low conflict rate is valid for some groupware usage scenarios where, for example, users practice social protocols such as turn taking. However, if this assumption cannot be made for scenarios in which a groupware application is to be deployed, it is better to use only pessimistic views.
Observe that the rate of concurrent updates to replicated model objects, and thus the conflict rate, are inherently dynamic variables that vary within and across usage scenarios. In many scenarios, concurrent updates may be bursty by nature. Long periods of time with low rates of concurrent updates may be followed by short periods of time with high rates of concurrent updates. In these situations, programmers of systems such as must make a difficult decision between optimistic and pessimistic views.
For example, consider a hypothetical collaborative spreadsheet application used by commodity traders to aid in their analysis of a commodity market. Usually, the traders are collaborating over a low-latency LAN, analyzing different commodities in a controlled environment. These factors, which reduce the number of concurrent updates in the system, will prompt a DECAF programmer to choose optimistic views to obtain a highly responsive spreadsheet application. However, breaking news stories or market events can occasionally cause the traders to frantically focus on a small number of commodities. The result is a large number of concurrent updates, causing the spreadsheet to recalculate repeatedly. At these times, the behavior of the application is not only distracting, but also confusing to the traders. This hampers the ability of the traders to execute trades in a timely manner.
Thus a need exists for a mechanism that can dynamically adapt to changing concurrency conditions and provide the benefits of both optimistic and pessimistic notifications. The present invention meets this need.